home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc807.txt < prev    next >
Text File  |  1994-08-01  |  11KB  |  349 lines

  1.  
  2.  
  3. Network Working Group                                          J. Postel
  4. Request for Comments:  807                                           ISI
  5.                                                          9 February 1982
  6.  
  7.  
  8.  
  9.                      Multimedia Mail Meeting Notes
  10.  
  11.  
  12.  
  13.  
  14. Introduction
  15.  
  16.    A meeting was held at USC Information Sciences Institute on the 12th
  17.    of January 1982 to discuss multimedia mail issues and experiments.
  18.    The list of attendees is at the end of this memo.
  19.  
  20. Overview:
  21.  
  22.    This meeting was called to discuss common interests in multi-media
  23.    computer mail experiments, and to agree on some specific initial
  24.    experiments.
  25.  
  26. Review of Status:
  27.  
  28.    Review current status of multimedia efforts at CMU, ISI, MIT, COMSAT,
  29.    BBN, UCL, SRI.
  30.  
  31.    CMU
  32.  
  33.       Using PERQ, Quip for fax, LPCM vocoder from LL, will get NEC board
  34.       (3 chips) to replace vocoder.  Will have a stand alone voice I/O
  35.       device that operates at 2400 baud (not packetized). Not working on
  36.       IP/TCP.  Will use the IP and TCP from the BBN project. Already
  37.       using the BBN Jericho developed Pascal IP and CFTP. Interested in
  38.       word recognition of LPC digitized voice data. Planning to package
  39.       a synthesiser, an analyzer, and a pitch tracker on one board.
  40.  
  41.    ISI
  42.  
  43.       Using TOPS20 (code in BLISS10), and starting to use PERQ (code in
  44.       Pascal), RAPICOM 450 for fax.  Main interest is in the data
  45.       structuring and message transport protocols.
  46.  
  47.    MIT
  48.  
  49.       Using Apollos, will program in MDL.  Use of Apollos still limited
  50.       due to (1) MDL not completely implemented, (2) network interface
  51.       not yet available (waiting on multibus  to then interface to
  52.       Ethernet). Will get NEC CCITT fax machine. Looking into VAX+BBN
  53.       BitGraph for future.  Main work to date in  design for sharing
  54.       message data in a conceptualy centralized filing system.  Emphasis
  55.  
  56.  
  57. Postel                                                          [Page 1]
  58.  
  59.  
  60.  
  61. Multi-Media Mail Meeting Notes                           9 February 1982
  62.  
  63.  
  64.       on efficient storage and manipulation of multirecipient messages,
  65.       enclosures, citations, etc.
  66.  
  67.    COMSAT
  68.  
  69.       Using small 11s, Rapicom 450 and 500 fax machines, also have some
  70.       LPC vocoders.  Substantial work has been done on encoding and
  71.       decoding both Rapicom 450 and CCITT T.4 fax data, and also on
  72.       manipulation of bitmap data (See RFC 803).
  73.  
  74.    BBN
  75.  
  76.       Using Jericho (code in Pascal). Will be building a prototype
  77.       system with the aim of investigating problems of data distribution
  78.       and privacy.  Trying to produce portable software currently in
  79.       Pascal but may switch to ADA in the distant future.  Have IP and
  80.       CFTP running, working on TCP. CFTP is a file transfer built
  81.       directly on IP.
  82.  
  83.    UCL
  84.  
  85.       Using LSI-11, Rapicom 450 fax machine, Grinell bitmap display.
  86.       May get PERQs (produced by ICL) in future.  Have done quite a lot
  87.       of work on encoding/decoding for the Rapicom 450, and in bitmap
  88.       manipulations (e.g., cleanup of noise, scaling, cut and paste).
  89.       Interests in the relation of other types of display protocols to
  90.       multimedia effort e.g., VIDEOTEXT and TELETEXT.
  91.  
  92.    SRI
  93.  
  94.       There are three multimedia mail projects at SRI,sponsored by DCEC,
  95.       ARPA, and NAVELEX.  SRI is a subcontractor (with Sytek and DTI) to
  96.       SDC in the DCEC program to produce protocol specifications for the
  97.       DoD.  SRI has written service specifications for a mail system
  98.       similar to RFC759+767 with security features added.  The ARPA
  99.       project is studying the issues involved in a multimedia mail
  100.       architecture based on RFC759+767, including negotiations,
  101.       envelopes, and multilevel security.  The NAVELEX project is
  102.       investigating user interfaces for command and control
  103.       workstations, including natural language access to a data base.
  104.       The plan is to use RFC759+767 data structures to communicate text
  105.       and graphics, implemented on Foonly F-5s running Tenex with
  106.       Foo-Vision displays.  The current choice for the graphics protocol
  107.       is Bisbey's GL2.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. Postel                                                          [Page 2]
  116.  
  117.  
  118.  
  119. Multi-Media Mail Meeting Notes                           9 February 1982
  120.  
  121.  
  122. Discussion:
  123.  
  124.    Coding/Decoding Algorithm:
  125.  
  126.       We agree to use the encoding specified in the CCITT T.4
  127.       recommendation for the exchange of black and white bitmap data.
  128.  
  129.    New Equipment:
  130.  
  131.       It is reported that soon NEC will have CCITT T.4 Group 3 Fax
  132.       machines for about $15K.
  133.  
  134.    NBS Mail Standard:
  135.  
  136.       The possibility that the NBS Mail Format Standard is a workable
  137.       alternative to the RFC759+767 protocol is to be studied.  What is
  138.       the relationship between these standards?  Do we have comment on
  139.       the NBS Standard to submit to NBS?
  140.  
  141.    Equipment Variations:
  142.  
  143.       What happens if the receiver does not have equipment capable of
  144.       protraying some of the data (e.g., dosen't have a  LPC vocoder)?
  145.       There are three subtopics:  How many "standard" forms are
  146.       allowed?, What do you tell the user if you can't do it?, and How
  147.       does the cost of a medium (in memory or cpu cycles or portrayal
  148.       time) effect its use? The general feeling was that if there is
  149.       some type of data the receiving system can't portray, it should
  150.       simply tell the user "There is some data here I can't portray and
  151.       it's type is x.". The other aspects are items for further study.
  152.  
  153.    Negotiation:
  154.  
  155.       Does negotiation make sense in a mail system?  What are the kinds
  156.       of things to be negotiated?  One possiblity is to initially send
  157.       only pointers to the sections of a message, and have the recipient
  158.       system ask for the parts it can handle.  Does this make sense in a
  159.       message relaying environment?  Or for messsages with a fine scale
  160.       interleaving of media types?  This topic is for further study.
  161.  
  162.    Enclosures, Pointers, Cross References:
  163.  
  164.       This seems too complex to handle at this meeting, so for now send
  165.       the whole thing.  This is an item for further study.
  166.  
  167.    Editing Multimedia Objects:
  168.  
  169.       This is one of the most interesting parts of these research
  170.  
  171.  
  172.  
  173. Postel                                                          [Page 3]
  174.  
  175.  
  176.  
  177. Multi-Media Mail Meeting Notes                           9 February 1982
  178.  
  179.  
  180.       projects, so each group will develop their own techniques, and we
  181.       will compare notes.
  182.  
  183.    Manipulation of Bitmaps:
  184.  
  185.       The issues involve aspect ratios, cut and paste, rotation  and,
  186.       scaling. We need to compare notes and exchange algorithms.  An
  187.       item for further study.
  188.  
  189.    Mailbox IDs and Control Information:
  190.  
  191.       With different types of source hosts and destination host
  192.       (timsharing systems, personal computers) and different types of
  193.       mail delivery schemes (append to file, query database server), do
  194.       we have sufficient control mechanisms and addressing modes?  This
  195.       is an item for further study.
  196.  
  197.    Storage and Transmission:
  198.  
  199.       How do the requirements for memory, disk, cpu, and transmission
  200.       capacity differ for multimedia mail from text mail? This is an
  201.       item for further study.
  202.  
  203.    Multimedia Virtual Message Format:
  204.  
  205.       It is not clear that this is anything different than what is
  206.       specified by RFC759+767, but since it was not fully discussed it
  207.       is an item for further study.
  208.  
  209.    Media Specific Protocols:
  210.  
  211.       Specific format definitions are needed for each media.  This is an
  212.       item for further study.
  213.  
  214.    Interfaces to Other Systems:
  215.  
  216.       How do we interface this multimeda system to opther systems (e.g.,
  217.       TELETEXT, VIDEOTEXT), and to text only mail systems (e.g.,
  218.       ARPAMAIL, TELEMAIL, ONTYM).  This is an item for further study.
  219.  
  220. An Experiment:
  221.  
  222.    BITMAP-TEXT DOCUMENT EXCHANGE
  223.  
  224.       Move the data between computers as a file, using any file transfer
  225.       method available.
  226.  
  227.       The File is a complete RFC 759 Document.
  228.  
  229.  
  230.  
  231. Postel                                                          [Page 4]
  232.  
  233.  
  234.  
  235. Multi-Media Mail Meeting Notes                           9 February 1982
  236.  
  237.  
  238.       Bitmap data is in revised COMSAT Image Data Format.
  239.  
  240.          Two compression types are to be used:
  241.  
  242.             Raw Bitmap
  243.  
  244.             CCITT Algorithm
  245.  
  246.       Text data is in RFC767 Paragraph Format.
  247.  
  248. Action Items:
  249.  
  250.    Start a New Note Series
  251.  
  252.       For the exchange of protocols, formats, algorithms, procedures,
  253.       and other information between the multiamedia mail projects.
  254.  
  255.       By: Jon Postel
  256.  
  257.       Due: 1-Feb-82
  258.  
  259.    Update RFCs 759 & 767
  260.  
  261.       To remove typos and clairfy ambiguities.
  262.  
  263.       By: Jon Postel
  264.  
  265.       Due: 1-Feb-82
  266.  
  267.    Update "Image Data Structure" Memo
  268.  
  269.       To be more generally for bitmaps and not so focused on fax only.
  270.  
  271.       By: Anil Agarwal
  272.  
  273.       Due: 1-Feb-82
  274.  
  275.    Compare and Contrast NBS Mail Standard with RFC 759+767 Protocol
  276.  
  277.       Would the NBS Mail Standard be an adaquate alternative to the RFC
  278.       759+767 approach?
  279.  
  280.       By: each site
  281.  
  282.       Due: Unspecified
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289. Postel                                                          [Page 5]
  290.  
  291.  
  292.  
  293. Multi-Media Mail Meeting Notes                           9 February 1982
  294.  
  295.  
  296.    Issue the NBS Mail Standard as an RFC
  297.  
  298.       To aid in wide consideration of it. (Where does the online file
  299.       come from?)
  300.  
  301.       By: Jon Postel
  302.  
  303.       Due: Unspecified
  304.  
  305.    Report on the differences between the NBS Mail Standard and other
  306.    things.
  307.  
  308.       What are the differences between the NBS standard and the
  309.       RFC759+767 protocol?, the IFIP plans?, the CCITT plans?, and the
  310.       ISO plans?
  311.  
  312.       By: Debbie Deustch
  313.  
  314.       Due: Unspecified
  315.  
  316.    Demonstrate FAX-TEXT Document Exchange
  317.  
  318.       This demonstration is to be ready before and repeated at the User
  319.       Interface Meeting at CMU.
  320.  
  321.       By: all sites
  322.  
  323.       Due: 19-20 April 82
  324.  
  325. Attendees:
  326.  
  327.    Duane A. Adams    DARPA/IPTO    Adams@ISI           (202) 694-8096
  328.    Vint Cerf         DARPA/IPTO    Cerf@ISI            (202) 694-3049
  329.    Harry Forsdick    BBN           Forsdick@BBN        (617) 497-3638
  330.    Bob Thomas        BBN           BThomas@BBND        (617) 497-3483
  331.    Gene Ball         CMU           Ball@CMUA           (412) 578-2569
  332.    Anil Agarwal      COMSAT        Agarwal@ISID        (301) 863-6103
  333.    David L. Mills    COMSAT        Mills@ISID          (202) 863-6092
  334.    Dave Lebling      MIT           PDL@MIT-XX          (617) 253-1440
  335.    Jon Postel        ISI           Postel@ISIF         (213) 822-1511
  336.    Greg Finn         ISI           Finn@ISIF           (213) 822-1511
  337.    Alan Katz         ISI           Katz@ISIF           (213) 822-1511
  338.    Carl Sunshine     ISI           Sunshine@ISIF       (213) 822-1511
  339.    David Elliott     SRI           wde@SRI-KL          (415) 859-4107
  340.    Andy Poggio       SRI           Poggio@SRI-Unix     (415) 859 5094
  341.    Zaw-Sing Su       SRI           ZSu@SRI-Unix        (415) 859-4576
  342.    Steve Kille       UCL           UCL-Netwiz@ISIE  (uk) (01)387-7050
  343.    Peter Kirstein    UCL           PKirstein@ISIA   (uk) (01)387-7050
  344.    Bill Tuck         UCL           UKSAT@ISIE       (uk) (01)387-7050
  345.  
  346.  
  347. Postel                                                          [Page 6]
  348.  
  349.